5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
+ Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
- Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 2-1: Data Dictionary Overview

Functions of a Domain


Each domain specification provides one or more of the following:

Storage definitions, from which APPX determines the internal storage length and format of any field that references the domain. A domain does not cause storage allocation. It simply defines the storage that APPX allocates when fields are created. Refer to the Fields section in this chapter for more information on physical storage allocation.

Display characteristics for items painted on an image, such as display masks or justification options.

Constraints and restrictions on a field's valid values, including range checks, validation tables, edit masks, and data lookup.

Other field attributes including column headings, descriptive names, default values, and security codes.

Domains contribute a number of significant benefits to the APPX application design process. They:

Minimize the development effort, by eliminating duplicate entry of common field attributes.

Minimize maintenance efforts, by providing a single location where changes flow through to all related fields in an application.

Ensure consistent database definition throughout the system. The length or edit attributes of a customer number, for example, never vary from Customer file to Invoice file to Cash Receipt file, etc.

It is important to note that the attributes defined for a domain apply to any field referencing that domain and cannot be overridden at the field level. Therefore, only define characteristics that are appropriate for each field subject to the domain. For example, since an employee number should have the same format and edit characteristics wherever it is used in the system, define such common attributes once in an employee number domain. However, if the descriptive name for employee number can vary from one field to another, leave Descriptive blank in the domain definition. This would enable, for instance, the Employee master file to contain two fields based on the employee number domain, each with an appropriate descriptive name (i.e., "Employee Number" for the employee's own number and "Supervisor Number" for the number of the employee's supervisor).

Application Design Manual                                         "Powered by Appx Software"

111

©2006 By APPX Software, Inc. All Rights Reserved